\chapter{Diseño de Software}

	% á
	% é
	% í
	% ó
	% ú
	% ñ

\section{Introducción}

 Desde el punto de vista de la ingeniería, el diseño de software es una etapa crucial del desarrollo de software, en la cual sus implicaciones y deficiencias afectan el proyecto a lo largo de su ciclo de vida, por lo que la toma de decisiones sobre el diseño es una tarea que debe ser llevada a cabo con especial atención y cuidado.
 El diseño de software\cite{libIng} puede dividirse en dos áreas:
\begin{itemize}
\item Diseño de alto nivel: En un diseño de alto nivel se describen los componentes principales del sistema y el modo en que 					interactúan entre sí para lograr los objetivos. Si se esta actualizando código existente, se describen los componentes
	principales y a continuación se agregan o modifican las interacciones entre los componentes.

\item Diseño de bajo nivel: Es la actividad técnica que sigue a la selección de la arquitectura. Es el último paso en la descomposición 		orientada a objetos en el que se llega a las unidades de programación (clases). Este nivel de diseño requiere 	encontrar un equilibrio 	adecuado entre abstracción y detalle.
\end{itemize}

 En este capítulo se realiza una descripción de la interacción existente entre los componentes del sistema, así también como la interacción entre distintos proyectos que \fudepan realiza. Se detallan decisiones de diseño con el fin de hacer notar variables que surgieron en distintos momentos del trabajo.


\section{Diseño de Alto Nivel}

\subsection{Descripción de la Arquitectura Existente}

 En la etapa de diseño, se plantea al sistema como un conjunto de componentes y conectores que denotan las tecnologías y partes involucradas en el mismo.\\

 Este diseño en particular contiene tres grandes partes: las librerías externas, la base de datos y el núcleo del sistema (ver Figura \ref{fig:EstructuraExistete}). De esta forma, se separa la funcionalidad propia del sistema, de todo aquello que resulta ajeno al proyecto, logrando así un sistema modular que garantiza poco acoplamiento.
 
% --- Comienzo del diagrama de arquitectura ASO

\begin{figure}
\def\blockdist{1.5}
	\centering
	\small
  	%\footnotesize
  	\begin{tikzpicture}[auto,
    block_center/.style ={rectangle, draw=black, thick, fill=blue!30,
      text width=8em, text centered, minimum height=4em},
    block_db/.style ={cylinder, draw=black, thick,  shape border rotate=90, fill=red!30, 
    	text width=5em, text centered, minimum height=0.4em},
    block_noborder/.style ={rectangle, draw=none, thick, fill=none,
      text width=18em, text centered, minimum height=1em},
    line/.style ={draw, thick, -latex', shorten >=0pt},
    line_dashed/.style ={draw, dashed, thick, -latex', shorten >=0pt}]
    
    \selectlanguage{english}

	% Cajas
    \matrix [column sep=13mm,row sep=10mm] {
	  % row 1
	    \node [block_noborder] (empty1) {};
      & \node [block_center] (biopp) {BioPP};
      & \node [block_db] (arvs_db) {Antiviral\\ DataBase};\\
      % row 2
        \node [block_center] (gui) {GUI};
      & \node [block_center] (therapyG) {Therapy Generator};
      & \node [block_center] (arvs_select) {Antiviral Selector};\\
 	  % row 3     
 	  \node [block_noborder] (empty) {};
      & \node [block_center] (mainP) {Main Program};\\
      % row 4
		\node [block_noborder] (empty2) {};
      & \node [block_center] (therapyR) {Therapy Ranker};\\
      % row 5
        \node [block_noborder] (empty3) {};
      & \node [block_center] (mili) {MiLi};\\
      };% end matrix
   
   	  % Flechas continuas
      \begin{scope}[every path/.style=line]
    		\path (gui) -- (mainP);
		\path (mainP) -- (gui);
    	  	\path (therapyG) -- (arvs_select);
    	    \path (arvs_select) -- (therapyG);
    	  	\path (arvs_select) -- node {FXP} (arvs_db);
    	  	\path (arvs_db) -- (arvs_select);
  		\path (biopp) -- (arvs_select);
	\end{scope}     
   
     
     % Caja ASO
     \begin{pgfonlayer}{background}
        \path (gui.west |- gui.north)+(-0.5,0.6) node (a) {};
    	\path (therapyR.south -| arvs_select.east) +(0.8,-0.5) node (b) {};        
          
        \path[fill=yellow!30,rounded corners, draw=black!50, dashed] 
        	(a) rectangle (b) node  (aso) {ASO};           
    \end{pgfonlayer}
	
	% Flechas discontinuas    
   	\begin{scope}[every path/.style=line_dashed]
		\path (therapyG) -- (mainP);
     	\path (mainP) -- (therapyR);
  		\path (mili) -- (aso);
  	\end{scope}
        
    % Caja AProba
    \begin{pgfonlayer}{background}
        \path (therapyG.west |- therapyG.north)+(-0.5,0.3) node (a) {};
        \path (arvs_select.south -| arvs_select.east)+(+0.5,-0.3) node (b) {};
          
        \path[fill=green!30,rounded corners, draw=black!50, dashed] 
        	(a) rectangle (b) node (aproba) {AProba};
    \end{pgfonlayer}
   
\end{tikzpicture}
\caption{\small Interacción entre componentes del sistema (ASO)}
\selectlanguage{spanish}
\label{fig:EstructuraExistete}
\end{figure}

\normalsize

\subsection{Descripción de la nueva arquitectura}

 Como se detalla en la Figura \ref{fig:DiagramaAproba}, nuestro trabajo interactúa con elementos y proyectos externos que brindan funcionalidades necesarias para la implementación de los pasos del algoritmo propuesto como solución en el capítulo anterior, sección \ref{sec:SolucionPropuesta}.

% --- Comienzo del diagrama de componentes
\begin{flushleft}
\begin{figure}[h!]
\def\blockdist{1}
\small
	\begin{tikzpicture}[auto,
    		block_center/.style ={rectangle, draw=black, thick, fill=blue!30,
      	text width=8em, text centered, minimum height=3em},
   		block_db/.style ={cylinder, draw=black, thick,  shape border rotate=90, fill=red!30,
      	text width=5em, text centered, minimum height=3em},
   	 	block_noborder/.style ={rectangle, draw=none, thick, fill=none,
      	text width=18em, text centered, minimum height=1em},
    		block_aso/.style ={rectangle, draw=none, thick, fill=none,
      	text width=10em, text centered, minimum height=3em},
    		line/.style ={draw, thick, -latex', shorten >=0pt},
    		line_dashed/.style ={draw, dashed, thick, -latex', shorten >=0pt}]
	
		\selectlanguage{english}

		% Cajas
    		\matrix [column sep=0.5mm,row sep=5mm] {
	  	% row 1
	  	\node [block_noborder] (empty1) {};
	  	& \node [block_center] (seq) {Sequence};
	  	& \node [block_noborder] (empty2) {};\\
      	% row 2
      	\node [block_noborder] (empty4) {};
      	& \node [block_center] (antiviralsS) {Antivirals Selector};
      	& \node [block_db] (arvs_db) {Antiviral\\ DataBase};\\
 	  	% row 3    
 	  	\node [block_noborder] (empty5) {};
 	  	& \node [block_center] (combinator) {Combinator};
 	  	& \node [block_noborder] (empty6) {}; \\
      	% row 4
      	\node [block_center] (mutants) {Mutants};
      	& \node [block_center] (ranker) {Ranker};
      	& \node [block_noborder] (empty8) {};\\
      	% row 5
      	\node [block_noborder] (empty9) {};
      	& \node [block_center] (mili) {MiLi}; \\
      	};% end matrix
   
   	  	% Flechas continuas
      	\begin{scope}[every path/.style=line]
    	  		\path (antiviralsS) -- (combinator);
			\path (combinator) -- (antiviralsS);
    	  		\path (combinator) -- (ranker);
    	  		\path (ranker) -- (mutants);
    	  		\path node {} (arvs_db) -- (antiviralsS);
			\path (antiviralsS) -- node {FXP} (arvs_db);    	  
  			\path (seq) -- node {BioPP} (antiviralsS);
     	\end{scope}
     
    	% Caja AProba
    	\begin{pgfonlayer}{background}
        	\path (antiviralsS.east |- antiviralsS.north)+(0.4,0.5) node (a) {};
        	\path (mutants.west -| mutants.south)+(-1.9,-1.1) node (b) {};          
        	\path[fill=green!30,rounded corners, draw=black!50, dashed] 
        	(a) rectangle (b) node (aproba) {AProba};           
       
		% Caja Av_Set
    	   	\path (mutants.west |- mutants.south)+(-0.1,-0.2) node (c) {};
        	\path (combinator.east -| combinator.north)+(1.8,1.1) node (d) {};          
        	\path[fill=yellow!30,rounded corners, draw=black!50, dashed] 
        	(c) rectangle (d) node (avset) {AV\_Set};           
    	\end{pgfonlayer}    
    
     	% Flechas discontinuas
     	\begin{scope}[every path/.style=line_dashed]
        		\path (mutants) -- (seq);
			\path (seq) -- (mutants);
			\path (mili) -- (aproba);
     	\end{scope}
	\end{tikzpicture}
	\caption{\small Diagrama de componentes de AProba}
	\label{fig:DiagramaAproba}
\end{figure}
\end{flushleft}

% --- Fin del diagrama de componentes

\selectlanguage{spanish}
\normalsize

 A continuación, se realiza una breve descripción de los componentes principales para este trabajo:

\begin{itemize}
	\item \textit{Sequence}: Contiene la secuencia nucleotídica que representa al virus.
	\item \textit{Antivirals Database}: Contiene información de todos los ARVs a través de un archivo XML\footnote{Para más información, ver sección \ref{xml}}.
	\item \textit{Antivirals\_Selector}: Componente encargado de la selección de ARVs de acuerdo a un criterio establecido.
	\item \textit{Combinator}: Componente encargado de generar las combinaciones de ARVs.  
	\item \textit{Ranker}: Componente encargado de la confección de un ranking conteniendo las mejores\footnote{Se considera que una combinación es mejor que otra, si su distancia genética respecto de la secuencia es menor.} combinaciones.
	\item \textit{Mutants}: Componente encargado de la generación de cepas mutantes a partir de un conjunto de combinaciones.
\end{itemize}


\subsubsection{Descripción del Funcionamiento} \label{sec:DescripFuncionamiento}

Como primer medida, se seleccionan aquellos antirretrovirales que pueden ser aplicados a la cepa inicial a través de un filtro por aplicación. A continuación se realizan uniones de hasta tres ARVs como máximo y se procede a la combinación de las mismas. A cada combinación se las somete a un ranking de acuerdo a una valoración, donde se aplica un filtro quedando las que se consideran mejores combinaciones. Por último, se generan todas las cepas mutantes que surgen de aplicar cada combinación a la cepa inicial.
Cabe destacar, que en todo el proceso de selección, combinación y ranqueado de antirretrovirales, se utiliza a \textit{MiLi} como librería principal de operaciones básicas.


\subsection{Diagrama de Paquetes}

El diagrama de paquetes muestra una perspectiva mas detallada del trabajo y provee una forma fácil y modular de introducirse al diseño del mismo.\\
A continuación se describen los paquetes involucrados en este proyecto.


\subsubsection{Antivirals}

La representación de antirretrovirales es central en este trabajo ya que son los elementos con los cuales se realizan todos los cálculos.

\begin{itemize}
\item \textbf{PseudoNucSequence:} Clase proveniente de BIOpp y representa a una secuencia de nucleótidos con varios métodos asociados para su manejo. Se representa como una cadena de cuatro posibles caracteres (A C G T).

\item \textbf{SequenceSet:} Tipo de datos que define a un conjunto de secuencias nucleotídicas.

\item \textbf{MutantDist:} Cuando un antirretroviral aplica sobre la secuencia, lo hace con una distancia genética determinada. Se considera tomar la menor de las distancias. Esta clase encierra al conjunto de mutantes y al valor mínimo que se consideró.

\item \textbf{DistanceMatrix:} Matriz de distancias genéticas que define el valor entre dos nucleótidos. Implementación derivada de BIOpp.

\item \textbf{Antiviral:} Clase que provee la interfaz de un Antiviral. Define un conjunto de funcionalidades básicas de un antirretroviral.

\item \textbf{ResitancePosition:} Clase que define a una posición de resistencia en particular. 

\item \textbf{ResisBasedAntiviral:} Implementación de un Antiviral basado en posiciones de resistencias.

\item \textbf{AntiviralSet:} Describe un conjunto de antirretrovirales y operaciones para el mismo.

\item \textbf{Mutant:} Tipo de datos que contiene información de la representación de una mutante.

\item \textbf{AntiviralSelector:} Uno de los mecanismos que utiliza el proyecto es el de poder seleccionar un conjunto de antirretrovirales que aplican a una secuencia. Esta clase provee esta funcionalidad colocando en un AntiviralSet, los antirretrovirales que cumplen con esta característica. 
\end{itemize}
	
\begin{figure}[h!]
\centering
\includegraphics[scale=0.45]{Pictures/Diagrama_Pack_Antiviral.png}
\caption{\small Paquete Antiviral}
\end{figure}
	
%\pagebreak

\subsubsection{DataBase}

\begin{itemize}
\item \textbf{DataBase:} Clase que engloba el concepto de la base de datos de antirretrovirales y todas las fucionalidades asociadas. Por ejemplo, la carga de un archivo XML.
\end{itemize}		

\begin{figure}[h!]
\centering
\includegraphics[scale=0.55]{Pictures/Diagrama_Pack_DB.jpeg}
\caption{\small Paquete DataBase}
\end{figure}


\section{Decisiones de Diseño}
 
 En esta sección damos una explicación detallada de las decisiones de diseño, como derivan de los requerimientos, de los principios de diseño (SOLID) y del uso de patrones de diseño.
 
 
\subsection{Elección del Tipo de Diseño}
Existen distintos paradigmas de diseño. Para el desarrollo de este trabajo tuvimos en cuenta los siguientes:

\begin{itemize}
\item El diseño orientado a datos (Data-driven design) es el resultado de adaptar métodos de diseño de tipos abstractos de datos a la 			programación orientada a objetos. Las clases se definen en torno a los datos de las estructuras que deben mantenerse.\\

\item El diseño orientado a responsabilidad (Responsibility-driven design) define clases alrededor de los términos de un contrato, es 			decir, una clase debe ser definida en torno a la responsabilidad y la información que comparte.
\end{itemize}

Finalmente se optó por el diseño orientado a datos, debido a que era el mas adecuado para este problema, ya que el código existente se encontraba dividido en clases y estructuras de acuerdo a los datos (antivirales, conjunto de antivirales, secuencias mutantes, etc.) en lugar de hacerlo a partir de las responsabilidades. Además, permite cumplir con los principios de SOLID de manera simple.
			
\subsection{Generación de datos basados en observadores}
 De los pasos 2, 3 y 5 del pseudo-algoritmo, descripto en la sección \ref{sec:analisis} del capítulo de Análisis, se desprende la necesidad de manejar los datos de forma diferente en cada paso.

\begin{itemize}
	\item En el paso 2 es necesario realizar el conjunto de partes, para lo cual se hace uso del motor combinatorio provisto 				por la fundación, utilizando una política combinatoria newtoniana. Dicha política retorna como resultado tantas combinaciones como 		lo indica el coeficiente binomial (todos los subconjuntos de tamaño K de un conjunto de tamaño N).

\begin{figure}[h!]
\centering
\includegraphics[scale=0.30]{Pictures/CombNewton.png}
\caption{\small Política de Combinación Compuesta.} 
\end{figure}	
	
	
	\item En los pasos 3 y 5 se necesita realizar el producto cartesiano sobre un determinado conjunto. Siguiendo la idea del paso 2, se utiliza el motor combinatorio, usando una política de combinación compuesta, la cual toma un grupo de algoritmos combinadores y une 	sus combinaciones a medida que éstas se generan. Se entrega al observador la unión de las combinaciones generadas por cada algoritmo que contiene.\\
\end{itemize}

\begin{figure}[h!]
\centering
\includegraphics[scale=0.30]{Pictures/CombComposed.jpg}
\caption{\small Política de Combinación Compuesta.} 
\end{figure}

\section{Diseño de Bajo Nivel}

\subsection{Interacción ASO/AProba}

 El proyecto ASO es el encargado de la generación de terapias de ARVs a partir de una secuencia viral inicial. Durante este proceso, necesita conocer todas las posibles mutantes que se obtienen a partir de la aplicación de una combinación de ARVs sobre la secuencia viral correspondiente a cada paso \footnote{Cabe destacar que al comienzo del algoritmo la secuencia viral corresponde a la obtenida a partir del secuenciador. El resto de las secuencias son derivadas de ésta (mutantes).}. \aproba es el responsable de brindarle a ASO, todas las posibles mutantes.
  
 En la Figura \ref{fig:DiagramaSecuencia} se detalla dicha interacción a partir de un diagrama de secuencias.

\begin{figure}
\centering
\includegraphics[scale=0.50]{Pictures/Diagrama_Secuencia.png}
\caption{\small Diagrama de Secuencia que describe la interacción entre ASO y AProba} 
\label{fig:DiagramaSecuencia}
\end{figure}

\subsection{Relación entre los componentes de \aproba} \label{sec:relacionaproba}

A continuación se detalla la actividad técnica que sigue a la descripción de la arquitectura seleccionada. Dicha actividad se expone mediante un Diagrama de Clases en la Figura \ref{fig:DiagramaClases}.

\begin{figure}
\centering
\includegraphics[scale=0.50]{Pictures/Class_Diagram.png}
\caption{\small Diagrama de Clases que describe la relación de los componentes \aproba} 
\label{fig:DiagramaClases}
\end{figure}

\newpage

\section{Base de Datos}

\subsection{Introducción}
Otro de los componentes externos al sistema es la base de datos de ARVs que son necesarios para la generación de las terapias. La base de datos es independiente, con lo cual puede ser manipulada o reemplazada sin acceder al código del software y que da libertad de poder configurarla con la información necesaria. Inicialmente se utiliza una base de datos genérica con los 19 ARVs provistos por \fudepan y que se listan en la sección \ref{arvs}.

\subsection{Base de datos genérica}
La base de datos que se incluye en este sistema provee información básica de los ARVs a utilizar como su nombre oficial, un id para indexación y un listado de grupos conteniendo resistencias. El formato elegido para su representación es XML.
También se anexa a la información, la clase y el tipo de ARV. Las distintas clases de ARVs son explicadas en la sección \ref{arvs}.

\subsubsection{Ejemplo de un registro en la base de datos}
Como ejemplo se muestra la forma en que se denota un ARV en la base de datos:

\begin{lstlisting}[language=XML, keywordstyle=\color{blue}, morekeywords={xmlns,version,type,id,class}]
<antiviral id="NRTI3" num = "3" type = "tRT" class = "cNRTI">
  <group min="0.5">
    <resistance pos="4" aminos="V" weight="1.0"/>
  </group>
  <group min="2.5">
    <resistance pos="6" aminos="T" weight="1.0"/>
    <resistance pos="10" aminos="V" weight="1.9"/>
  </group>
</antiviral>
\end{lstlisting}


\subsection{Agregar información a la base de datos}

La información incluida en la base de datos es la mínima indispensable para poder realizar los cálculos requeridos por el sistema, como ser la aplicación de un ARV a una secuencia. Con lo cual, las posiciones de resistencia son los datos principales para poder ejecutarse en caso de que elijamos plantear aplicaciones por resistencias. ¿Pero, qué sucede si queremos considerar otras variables como atributos extra que posea el ARV, por ejemplo, su toxicidad, costo, entre otras, y que son cruciales para la elaboración de una terapia?. Para estos casos, se permite anexar esta información a la base de datos (addendum).

\subsection{Addendum}
Se definió con este nombre a la extensión de los datos de un ARV en la base de datos.
De forma muy simple se puede colocar un nuevo conjunto de atributos con su valor. Para ésto se agrego la siguiente linea luego de la especificación de las resistencias:

\begin{lstlisting}[language=XML, keywordstyle=\color{blue}, morekeywords={xmlns,version,type,id,class}]
...
<addendum attrib="price" value="34"/>
<addendum attrib="toxicity" value="0.34"/>
<addendum attrib="pregnancy" value="1"/>
...
\end{lstlisting}

Para garantizar la completitud y correctitud de los datos se debe corroborar que las nuevas variables estén presentes en cada una de las definiciones de los ARVs y que éstas sean correctas, por ejemplo, que el valor de un aminoácido sea realmente un aminoácido. La razón es que el sistema no pre-procesa la base de datos en búsqueda de inconsistencias. Es decir, que los datos sean correctos dependerá del contexto del cálculo que se desee realizar.















